src/it/MWAR-389/verify.bsh:84

• mainLib.list() can return null, which will cause a NullPointerException when iterating mainJars. Add the same directory/list guards used elsewhere in the IT suite.

String[] mainJars = mainLib.list();
boolean mainHasOld = false;
boolean mainHasManaged = false;

for ( int i = 0; i < mainJars.length; i++ )

src/main/java/org/apache/maven/plugins/war/packaging/OverlayPackagingTask.java:70

• filterConflictingDependencyJars() deletes JARs directly out of the overlay temp directory (tmpDir). Because unpackOverlay() intentionally caches the unpacked overlay when the overlay artifact timestamp hasn’t changed, those deletions will persist across subsequent builds without a clean — even if the project dependency set changes and the overlay JAR should be included again.

                // Step1b: Remove jars from overlay that conflict with managed dependencies
                filterConflictingDependencyJars(context, tmpDir);

src/main/java/org/apache/maven/plugins/war/packaging/OverlayPackagingTask.java:201

• extractArtifactId() assumes the first digit in the filename marks the start of the version. That fails for artifactIds that themselves contain digits (e.g. commons-lang3 → commons-lang3-3.20.0.jar), causing artifactId extraction to return null and the overlay JAR never to be filtered.

        int versionStart = -1;
        for (int i = 0; i < baseName.length(); i++) {
            if (Character.isDigit(baseName.charAt(i))) {
                versionStart = i;
                break;

src/main/java/org/apache/maven/plugins/war/packaging/OverlayPackagingTask.java:176

• The debug message says the removed dependency is the “managed version”, but the current logic is based on the resolved runtime dependency set and may include non-managed dependencies. Tweaking the message would avoid misleading diagnostics.

                context.getLog()
                        .debug("Removing dependency [" + jarName + "] from overlay [" + overlay.getId()
                                + "]; managed version in project already provides it");

src/main/java/org/apache/maven/plugins/war/packaging/OverlayPackagingTask.java:193

• getJarGroupId(overlayJar) opens and scans each jar, even when the extracted artifactId is not present in projectFallbackIds and therefore can never match. A straightforward optimization is to first check projectFallbackIds.contains(artifactId) and only then open the jar to resolve groupId for precise matching.

        for (File overlayJar : overlayJars) {
            String jarName = overlayJar.getName();
            String artifactId = extractArtifactId(jarName);
            if (artifactId == null) {
                continue;
            }

            String groupId = getJarGroupId(overlayJar);
            String key = (groupId != null) ? groupId + ":" + artifactId : artifactId;

src/main/java/org/apache/maven/plugins/war/packaging/OverlayPackagingTask.java:230

• The current approach mixes metadata-based matching (groupId from pom.properties) with filename parsing for artifactId. Since META-INF/maven/<groupId>/<artifactId>/pom.properties already includes both coordinates (and the path itself encodes them), consider extracting both groupId and artifactId from the META-INF/maven/.../pom.properties entry when present, and only falling back to filename parsing when the metadata is absent. This improves correctness for jars whose filenames don’t match artifactId-version... and reduces reliance on heuristics.

    /**
     * Reads the Maven groupId from a jar's {@code META-INF/maven/**\/pom.properties} metadata, if
     * present.
     *
     * @param jarFile the jar file
     * @return the groupId, or null if it could not be determined
     */
    private static String getJarGroupId(File jarFile) {
        try (ZipFile zip = new ZipFile(jarFile)) {
            Enumeration<? extends ZipEntry> entries = zip.entries();
            while (entries.hasMoreElements()) {
                ZipEntry entry = entries.nextElement();
                String name = entry.getName();
                if (name.startsWith("META-INF/maven/") && name.endsWith("/pom.properties")) {
                    Properties props = new Properties();
                    try (InputStream is = zip.getInputStream(entry)) {
                        props.load(is);
                    }
                    return props.getProperty("groupId");
                }
            }
        } catch (IOException e) {
            // groupId not available; fall back to artifactId-only matching
        }
        return null;
    }

src/main/java/org/apache/maven/plugins/war/packaging/OverlayPackagingTask.java:255

• The current approach mixes metadata-based matching (groupId from pom.properties) with filename parsing for artifactId. Since META-INF/maven/<groupId>/<artifactId>/pom.properties already includes both coordinates (and the path itself encodes them), consider extracting both groupId and artifactId from the META-INF/maven/.../pom.properties entry when present, and only falling back to filename parsing when the metadata is absent. This improves correctness for jars whose filenames don’t match artifactId-version... and reduces reliance on heuristics.

    /**
     * Extracts the Maven artifactId from a jar filename following the
     * {@code artifactId-version(-classifier)?.jar} convention.
     *